Predictable pointer acceleration 


e Overview 
e The problem 
- In theory and practice 
e The solution 
- Selected details 
e Impact 
- Guidelines for input drivers 
e Outlook 


Predictable pointer acceleration simon. thum@gmx. de 


Ad-hoc census 


e Who noticed a change in pointer behaviour ? 
e Who changed settings in response ? 
e Who even switched profiles or did other experiments ? 
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From 10.000 feet 


e X pointer acceleration previously 
- Very simple 
- Often seen as inadequate 
- It ‘feels bad' 
e longstanding issues 
- No scaling in dix 
e Leads to driver side scaling 


- distributed buffers 
- Parallel acceleration (synaptics) 


- Sometimes overshoots 
> One could do better 
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The problem - in theory 


e Useabilitv depends on predictabililty 
e The brain knows velocity, the computer knows mickeys 
- Mickeys and velocity correlate 


- (but that's pretty much all there is) 


e With acceleration, there's a disconnect 


- The X user is forced to learn how his mouse generates 
mickeys 


> Need to restore the feedback loop 
> Talking about the same thing is a good start 
> users should have more control 
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The problem - in practice 


e Mickeys just don't suffice 
- Mickey is [L], velocity is (Ege 
- Dynamic range is very low 


e Slow motion: ~ 1:3, uneven 
- 'High-Performance' devices: trade dynamic range for 
responsivity 
e Faster: ~1:15 
- Blocked X jeopardizes mickey 
e Resulting acceleration varies 
> We need a proper velocity 
> Have it or fake it 
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Data flow 


(abbrev. ) 


From mickey to velocity 


1)Divide by delta time 
v Great for estimating slow motion 


v Bumps dynamic range - 1:50 easily 
- Still very dependent on individual Mickeys 
- Creates need to scale estimate 

e Velocity is pixel per scale milliseconds 


2) Tracking velocity with filters 
v Even and dynamic velocity 


— responsivity 


>'Good estimation' becomes 'good filter setup & 
selection' 
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Velocity tracking 


e Multiple filters 
e Short half-life: tight tracking 


e Long half-life: smooth ‘average’ 
e Better stability by design 


e Select good filter by divergence 
e Details may change 


e Sometimes override filters (coupling) 
e Responsive 


e Good compromise esp. for 1 filter 
e Responsive to noise too 
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| | Primary User controls 


Velocity and then 2 


e Profiles 
- Translate device velocity to acceleration factor 


- To be chosen on individual preference 
- Should be smooth to be intuitive 


e Previously they weren't 
e Adaptive deceleration 
- Great for precise pointing 


e Constant deceleration 
- better adapt to a large device range 
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Impact 


e Scaling in drivers considered harmful 
- Except to suppress errors 


- Better postpone scaling to avoid multiple independent 
buffers (remainders) 


- precision otherwise unavailable 


e API allows to coordinate on scaling or acceleration 
- It's not neccessary for a driver to benefit 


- Main use: postpone scaling 
- driver-specific profile 


e Pressure or other sensor input 
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Outlook 


e Expose device properties 
- Cool UI stuff 


- Upload user-defined profiles 


e More numerical stability 
- Change default acceleration 
e Accelerate e.g. Z axis 
e velocity and sub-pixel position 
- Make some sense now 
- could be of use down the chain 


e Move more transforms into dix 
- AngleOffset 
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